home *** CD-ROM | disk | FTP | other *** search
/ CU Amiga Super CD-ROM 2 / CU Amiga Magazine's Super CD-ROM 02 (1996)(EMAP Images)(GB)[!][issue 1996-04].iso / misc / sadeness_software / bonus-stuff / top5 / damagewolf_v2 / wolf3d-info.txt < prev    next >
Text File  |  1996-02-12  |  14KB  |  319 lines
  1.                   Hypnosis - The 8 States of Unconsciousness
  2.  
  3.                               (DamageWolf3D V2.0)
  4.  
  5.  
  6.                          Codex:  STL of Damage Finland
  7.                                 (Antti Lankila)
  8.  
  9.                 AGA GrApHiCs:  Bartosz Boruta a.k.a.  Peek@IRC
  10.  
  11.                    Testing hardware support:  Peek (Thanks)
  12.  
  13.                           Quality Assurance: *@*  :)
  14.  
  15.  
  16. REQUIREMENTS:
  17.  
  18.     at least
  19.     68000   / OCS / .5MB CHIP, 1MB FAST / 1.2  (A500++)
  20.  
  21.     recommended
  22.     68030++ / AGA / 2MB CHIP,  1MB-xMB FAST
  23.  
  24. PROBLEMS:
  25.  
  26.     A4000/040 - works only briefly.  This applies to *all* lower processors
  27. too,  but  the  mean  time before the crash increases exponentially.  This is a
  28. sudden  engine jam - seems to occur even more likely when jumping.  I am trying
  29. to kill this bug on top priority.
  30.  
  31. KNOWN BUGS:
  32.  
  33.     A certain sized screen seem to be able to crash the machine sometimes -
  34. F8 enters a pixel-doubled mode, which seems more vulnerable on some occasions.
  35.  
  36.     The  inside  corners  of  walls fail quite pathetically 99% of time - a
  37. pixel-width slice of sky is displayed instead of the intended wall.
  38.  
  39.     Too  near  observation  of  walls  (and  sky)  causes  ceiling  stripes
  40. (texture)  to  flood  down,  sky  rendering  blankouts,  interesting  mess  and
  41. sometimes even Guru 5.  Beware.
  42.  
  43.     The jumping reaches one pixel too high (ouch) ;)
  44.  
  45.     The  dithering  colours  look  a  little  weird  at certain distances -
  46. hopefully it functions better on AGA.
  47.  
  48.     With  ceiling  disabled,  a line-high piece of sky is rendered where it
  49. should not be.  This occurs at certain directions only.
  50.  
  51. FUTURE:
  52.  
  53.     A Game.
  54.  
  55.     Support for Graffiti chunky graphics card (yeah!).
  56.     .. extensive support for other graphics cards ..
  57.  
  58.     PD -> Shareware?
  59.  
  60.  
  61. V1.0 - V2.0 developement info ignored: major rewrite - not relevant
  62.  
  63. V2.0 - Still a fucking walkaround demo - "AGA" gfx ;) - released
  64.  
  65. · Primary AGA texture file support
  66. · 128x128x8 textures.
  67. · 90 degrees vision.
  68. · ExtraHigh mazes
  69. · Sky
  70.  
  71. (not that much of improvement after all :-)
  72.  
  73. *** Some LeGaL stuff:
  74.  
  75. This  game  is  PD.   No  fees  except  a  small  copying  fee  is allowed.  No
  76. distributions  through  PD  companies  without  my permission (excluding Aminet
  77. collections and Fred Fish).
  78.  
  79. I  am not responsible for any losses of any kind of data that might, are or are
  80. not,  caused  by this program or any of the other files required for DamageWolf
  81. to  operate,  or  supplied  with this archive on the original state, which also
  82. means  that  you must kindly leave the archive intact thank you very much.  Let
  83. me  exclude Alla(s|h) who will nail me to the wall if I won't let him advertise
  84. his BBS.
  85.  
  86. Phew.  Now lets go to the traditional DMGWolf release information.
  87.  
  88.  
  89. The   graphics   for   this   engine   have   been  drawn  by  Bartosz  Boruta,
  90. boruta@omk.il.pw.edu.pl,  Peek@IRC  on  #amigapl,  #amiga  and  so  on.   These
  91. graphics obey an AGA palette and AGA iff form, but due to some problems, we are
  92. sticking  on  only  the  EHB-side  colours  yet.  You might experiment with AGA
  93. colours  yourself - tell us the results then, too.  Basically, AGA colours work
  94. even on EHB and are realtime converted via dithering.
  95.  
  96. I  still  don't own an 1200 and without the new Kickstart I would have gone mad
  97. supporting  AGA;  I  did  not  have to write my own support system for 256c IFF
  98. files (to even see them).
  99.  
  100.  
  101. This  Wolf3D  clone  leaves my HD without real beta-testing.  So I am sorry for
  102. any  at-the-moment-unknown bugs that exist.  To run the Wolf3D succesfully, you
  103. need to follow the file hierarchy introduced in the archive.  Each data file on
  104. your  HD  needs to be placed like they are placed in the archive.  The dir tree
  105. looks something like this (only a brief example):
  106.  
  107. current directory:
  108.  
  109. tris  (dir)
  110.     nottriangle-hole.256
  111.     nottriangle-main.256
  112.     nottriangle-blah.256
  113.     nottriangle-lahb.256
  114.     nottriangle-ahbl.256
  115.     nottriangle-hbla.256
  116. blue  (dir)
  117.     whiteblue1.256
  118.     whiteblue2.256
  119. just_some_gfx  (dir)
  120.     blah blah texture 1.256
  121.     blah blah texture 2.256
  122.     blah blah texture 3.256
  123. recalcscreen.ehb
  124. Scenery.chraw
  125. Wolf3D-BB.EXE
  126. MapEditor
  127. MAP
  128.  
  129. etc..
  130.  
  131. A misplaced file can not be located by the engine.  This will cause memory junk
  132. to  be  displayed  instead  of  the  desired  texture  (or blank zeros..  Can't
  133. remember  ;).   The  Wolf will not crash even on case of all the files missing,
  134. but it won't look too exciting either.
  135.  
  136. The  Wolf3D, Mapeditor and MAP should reside at the example's Current Direcory.
  137. The  Wolf3D  assumes that the current directory used when the Wolf3D was run is
  138. the  root directory for the Wolf3D's data files.  The WMAP file is a script and
  139. should be at 'S:'.
  140.  
  141. Wolf3D  will not function from disks - it will be a HD only game.  It will take
  142. about  3-5  M  of  disk  space.  The current version might still work - I don't
  143. know.  To use it on disks is annoyingly slow at any rate.
  144.  
  145.  
  146. The gfx style owes a little to ROTT, DOOM, Heretic (and 99% of the Amiga clones
  147. around, too) and the person Arctangent (Thanks for letting us to use your gfx),
  148. whose  textures  were  found on Aminet.  I won't single any textures out out of
  149. the  currently  used  gfx,  because I have quite a huge library of textures for
  150. this  ROTT clone, and the filenotes are there to tell everything needed (I hope
  151. they still remain).
  152.  
  153. The  90°  vision  was something I added due to Wolfenstein3D, DOOM, Heretic and
  154. ROTT.   Now  DamageWolf  looks much more like one of those.  The actual view of
  155. our own eyes is about that 90° and so this attempts to mimick the real thing...
  156. Not!   Sorry.   The  corners  stretch  the  most unrealistic way and the floors
  157. sprain brilliantly strangely.  Welcome to 90 degrees!  :-)
  158.  
  159. The Height/look-up'n'down routines were written after hours of ROTT experience.
  160. This  also  means  that  DamageWolf has no precalculated information except the
  161. most   required;   I  removed  about  every  one  of  the  previously-essential
  162. precalculations  and  kicked  in  completely  new  realtime  algorithms  - more
  163. flexibility etc.  you understand :-)
  164.  
  165. The  sky  is  my  own implementation of both dimension stretches - normally the
  166. _NECESSARY_  Y-stretch  is  ignored.  Looks damned ugly - just look at DOOM and
  167. Heretic  or  whatever!  Why is that, it does not even optimize (or at least not
  168. very  much).   I  hope  you  like  Mountains  that look a little more like they
  169. should.  They are drawn-calculated by my gfxman.  I wonder what this Wolf clone
  170. would  have  become  if it wasn't for Bartosz Boruta, who kicked me hard enough
  171. (and  /dcc'd  his  willpower  every time necessary) to force me to do something
  172. serious.  I hope you agree :-)
  173.  
  174.  
  175. I  am not going to make any barriers for editing the Wolf3D (No, I am not gonna
  176. publish  it  under  GNU  however  ;).   This is why the gfx files are perfectly
  177. normal  .iff  format  (This  little  improvement  took  damned two hours!), the
  178. will-be-samples  will  be replacible and this is also why a real map editor was
  179. made.   I  hope  that  you Amiga freaks will have fun making your own Talvisota
  180. Simulaattori  and  designing  your own game (when I get it coded that is).  The
  181. only  real  limit is that the palette of the iff files must be left intact.  If
  182. you  use  our  gfx,  please give the credit to the appropriate persons too.  Or
  183. what  do you say, Bartosz?  Only the mountain file is a special chraw file that
  184. can  not  be  generated  by  the  user,  unless  there is a good iff converting
  185. software.   The  format for that file is 320x256 ordinary chunky rotated 90/270
  186. degrees,  using  our AGA palette (this file is AGA even tho the others are not,
  187. some pre-taste about what my AGA-EHB converter can really do ;).
  188.  
  189.  
  190. All  KS2.0++ owner dudes, you may now happily bang your keyboard as much as you
  191. wish and it should still work ok at the end :-) ..  It wasn't an A1200 keyboard
  192. bug,  but  a  problem  of  KickStarts'  different CIA timer settings (well well
  193. well).   After  I upgraded to 40.68 I was instantly faced with the same problem
  194. and I could finally solve it (blush).
  195.  
  196. However,  the A1200 keyboard still can't handle all of the simultaneous presses
  197. so  don't blame me if you can't go forwards while pressing sidewalks, rotating,
  198. jumping  and  looking down etc.  That's a hardware problem.  I doubt if you can
  199. do all that at the same time either ;)
  200.  
  201. Numeric keyboard controls:
  202.  
  203.  
  204.         [        ]        /        *
  205.       sidewalk left      move forwards      sidewalk right       Jump
  206.  
  207.  
  208.         7        8        9        -
  209.         turn left      move forwards       turn right       Look upwards
  210.  
  211.  
  212.         4        5        6        +
  213.         turn left     move backwards       turn right      Look downwards
  214.  
  215.  
  216.         1        2        3        E
  217.         turn left     move backwards       turn right        ;open doors
  218.  
  219.  
  220.         0                .
  221.        running mode
  222.  
  223.  
  224. And ...  ramiga should make the turning keys do sidewalk, shift should make you
  225. virtually  run,  F10 will flip between OCS/AGA modes and F8 will toggle a pixel
  226. doubler  on/off.   The  one  between,  F9, flicks one bit in memory that has no
  227. function  at  all.   That's  it I think.  The final key assignment will be much
  228. like DOOM's.
  229.  
  230.  
  231. The  WMAP  file and MapEditor are files needed for mapediting.  The former is a
  232. KS2.0++  script  to edit a file (usage:  WMAP "<map file name>").  It will need
  233. slight editing (you are not likely to use the same path definitions that I do),
  234. but  the  basic  idea  should  be the same.  MapEditor is the actual map editor
  235. executable.  Like the Wolf, it will attempt to load the gfx files to be able to
  236. display  them during the editing of the map.  The MapEditor.help deals with the
  237. editor more spesifically.
  238.  
  239. I apologize for the proportionally large sizes of the executables and map files
  240. -  shit happens.  They all crunch VERY heavily, especially the map editor; what
  241. would  it be, 5% left after lzx'ing I assume.  :) Both are mostly nulls (Wolf3D
  242. uses bss hunks so I know about THAT, it is just that that I am lazy ;).
  243.  
  244. The map editor might represent some difficulties for a newcomer.  The hest help
  245. file  is  experience.   I hope you will have a happy time examining the cryptic
  246. methods that are used to create a map with the editor ;)
  247.  
  248.                                   The Engine
  249.                                   ----------
  250.  
  251. 1.  Special section:  Ray Casting enhancements in DamageWolf3D
  252.  
  253. The  actual  casting  is  omitted as it is quite normal although very rayfiring
  254. based, but not so iterative however :-)
  255.  
  256. The Ray Casting involves tracing quite far on some occasions.  I'll tell you an
  257. optimation  that  helps especially when looking straight at the end of the maze
  258. where  the  outside  is about nulls (and yet another of the casts has to travel
  259. there).   If  the first cast hits at distance, say, 50, then the second is only
  260. needed  to  be  casted  to that distance and not further.  This is for the fact
  261. that  even  if  something  was  found,  it would be blocked by the first cast's
  262. results anyway.
  263.  
  264. It  is VERY likely that the cast that gave the wall coord last time returns the
  265. wall  coord this time time too, and due to the ray-blocking feature, the second
  266. cast  is  not  needed to be casted to the extreme backwaters of the map, but it
  267. can  be  cancelled  at  the point of the end of the first cast, thus, expensive
  268. processor time gets saved.  This method is completely errorproof in results and
  269. still very useful.
  270.  
  271. I  also  read that the floors can not be handled with ray casting.  Perhaps not
  272. in  the  wall solving loop (it isn't even wise), but casting is a powerful tool
  273. to   manage  the  floor  anyway.   As  the  floor  in  DamageWolfV2.0  uses  no
  274. precalculated  tables  -  simply  because  for  all  the  heights  and  looking
  275. directions (angles and up/dward possibilities) there is and would not be enough
  276. memory  -  the  V2.0's  replacement  routine  to  V1.6  is in fact based on ray
  277. casting.   This  is  only  for  your  curiosity  :-).   Compared  to the wall's
  278. rendering  loop  it  runs on almost equal speed!  Even though the floor is much
  279. more  tricky  -  imagine  that walls is only a string of values that need to be
  280. stretched or shrinked so that the original contents fill a desired length.  The
  281. floor  is  a (x,y) array of X * Y bytes where the same stretch takes its values
  282. from  a line that goes thru this 2D array.  So there is more with the rendering
  283. of the floors.
  284.  
  285. I  have  been  asked  to  tell  about  my  C2P converter.  So - this is for the
  286. interested people:  The chunky to planar algorithm writes to a scrambled buffer
  287. (some  c2p passes deleted), and 35% of the rest is completed with the CPU - the
  288. stillexisting optimized remains of the first sweep of c2p_020_fastram.a, having
  289. 6th and 7th planes support entirely deleted.  The excretements of the processor
  290. are  dumped  to a asynchronous blitter task, which, without any futher notices,
  291. converts the rest in the background.
  292.   The processor parts exists due to the faster Chunky buffer access as it is in
  293. Fast memory.
  294.   That  was  it  for  the  OCS.   For  the  AGA mode, I use c2p_020_fastram.a's
  295. slightly clipped version (sorry, no blitter algorithm here).
  296.  
  297.                                       ***
  298.  
  299. Enough.   N-joy,  have  fun,  explore.   Hope  it works on all the machines you
  300. people own :) ..  If you have comments, suggestions or questions, just mail me.
  301. Any mail would be most welcome.
  302.  
  303. Said in an irc script way...:
  304.  
  305. /set cmdchars ./
  306. .notify STL
  307. .notify Peek
  308.  
  309.  
  310. I  am about to have an holiday, length of a week.  Do not be surprised if there
  311. is  no  reply  during  2x.10.   After  that  time I will be firmly stuck in the
  312. computer class again.
  313.  
  314.  
  315. * STL / Damage --- Antti Lankila  --- andezl@kastelli.otol.fi *
  316. * Peek         --- Bartosz Boruta --- boruta@omk.il.pw.edu.pl *
  317.  
  318. -STL
  319.